Skip to content

arch: arm: cortex_m: Consolidate SCB APIs and add backup/restore functions #93161

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 24, 2025

Conversation

msmttchr
Copy link
Contributor

This pull request aims to centralize and enhance the System Control Block (SCB) related APIs within the Arm Cortex-M architecture layer.

It adds of SCB Register Backup/Restore Functions by new utility functions (scb_backup_registers and scb_restore_registers) for safe preservation and restoration of essential SCB register states. This functionality is crucial for advanced features such as suspend to RAM scenarios.

See also #90001

@github-actions github-actions bot added the area: ARM ARM (32-bit) Architecture label Jul 15, 2025
@msmttchr msmttchr force-pushed the scb_management branch 2 times, most recently from f56c70c to 1df36d5 Compare July 16, 2025 08:22
Copy link
Contributor

@wearyzen wearyzen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

may I ask where do you plan to use these new apis and if you plan to move all such apis from https://github.com/zephyrproject-rtos/zephyr/blob/34e47f4040c99d52fe0e5d5eb64b2904e14f8981/soc/nordic/nrf54h/pm_s2ram.c to arm folder?

@msmttchr
Copy link
Contributor Author

may I ask where do you plan to use these new apis and if you plan to move all such apis from https://github.com/zephyrproject-rtos/zephyr/blob/34e47f4040c99d52fe0e5d5eb64b2904e14f8981/soc/nordic/nrf54h/pm_s2ram.c to arm folder?

I plan to use in either in soc specific implementation of suspend to RAM or move in the centralized suspend to RAM functions of Cortex M series.

I do not plan to move all the API from such file to arm folder but actually taking inspiration and extract what could be general and not soc specific. I also added modification to scb_backup and scb_resume functions since I believe the backup and restore of some registers is not needed or wrong.

@msmttchr msmttchr force-pushed the scb_management branch 2 times, most recently from 5741c66 to e657f97 Compare July 19, 2025 10:02
@zephyrbot zephyrbot requested review from dcpleung and nashif July 19, 2025 10:03
@JarmouniA JarmouniA self-requested a review July 19, 2025 11:02
Copy link
Contributor

@mathieuchopstm mathieuchopstm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise LGTM.

Copy link
Contributor

@mathieuchopstm mathieuchopstm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, one more remark:

Copy link
Contributor

@wearyzen wearyzen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also request to have the .c and .h in the same commit (the 2nd commit with just .h doesn't make much sense to me)

@msmttchr
Copy link
Contributor Author

I would also request to have the .c and .h in the same commit (the 2nd commit with just .h doesn't make much sense to me)

Done

Copy link
Contributor

@mathieuchopstm mathieuchopstm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise LGTM. -1 because Cortex-M3 has CPACR

Add two API to save SCB context and restore it, typically
used in suspend to RAM use case.

The scb_context_t and the backup/restore functions are designed to only
handle SCB registers that are:
- Mutable: Their values can be changed by software.
- Configurable: They control system behavior or features.
- Stateful: Their values represent a specific configuration that an
            application might want to preserve and restore.

Register excluded from backup/restore are:
1.	CPUID (CPUID Base Register)
	Motivation for Exclusion: This is a read-only identification register.
2.	ICSR (Interrupt Control and State Register)
	Motivation for Exclusion (from restoration): While its current value
	can be read, directly restoring a saved	ICSR value is highly
	dangerous and generally unsafe in an RTOS context.
	Contains Read-Only Status Bits: A significant portion of ICSR
	consists of read-only bits (VECTACTIVE, VECTPENDING, ISRPREEMPT,
	TSRUNPEND). These bits reflect the current state of the exception
	system (e.g., which exception is active, which are pending) and are
	managed dynamically by the CPU and the RTOS.
	Forcing a previous state onto these bits would corrupt the live
	system's interrupt handling.
	Contains Write-Only Set/Clear Bits: Some bits are write-only to set
	or clear a pending interrupt (PENDSVSET, PENDSVCLR, SYSTICKSET,
	SYSTICKCLR). If these bits were set in the saved context, restoring
	them might immediately trigger an interrupt or change its pending state
	unexpectedly, outside the RTOS's control.
	RTOS Management: In Zephyr (and other RTOSes), the kernel tightly
	manages the interrupt and exception state.
	Direct manipulation of ICSR's volatile bits could conflict with the
	RTOS's internal state machine, leading to crashes or unpredictable
	behavior.
3.	CFSR (Configurable Fault Status Register)
	Motivation for Exclusion: This is a read-only status register that
	reports the current state of Memory Management, Bus Fault, and Usage
	Faults. It's used by fault handlers to determine the cause of a fault.
4.	HFSR (HardFault Status Register)
	Motivation for Exclusion: Similar to CFSR, this is a read-only status
	register that reports the current state	of HardFaults. It's for
	reporting, not for configuration or restoration.
5.	DFSR (Debug Fault Status Register)
	Motivation for Exclusion: This is a read-only status register that
	reports debug-related faults. It's primarily used by debuggers and
	is not part of the application's runtime context to be saved/restored.
6.	MMFAR (MemManage Fault Address Register)
	Motivation for Exclusion: This is a read-only register that stores the
	address that caused a Memory Management	fault. It's a diagnostic
	register, not a configurable parameter.
7.	BFAR (BusFault Address Register)
	Motivation for Exclusion: Similar to MMFAR, this is a read-only
	register that stores the address that caused a BusFault. It's a
	diagnostic register.
8.	AFSR (Auxiliary Fault Status Register)
	Motivation for Exclusion: This register is implementation-defined and
	read-only.

Signed-off-by: Michele Sardo <[email protected]>
Copy link

@mathieuchopstm mathieuchopstm requested a review from wearyzen July 22, 2025 15:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Architectures area: ARM ARM (32-bit) Architecture
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Suspend to RAM feature not taking care of all cortex-m hw reinitializations
6 participants